Pull request overview

Fixes hit-testing for very narrow rendered RX filter passbands in SpectrumWidget so dragging inside the passband reliably moves the slice (VFO drag) instead of accidentally initiating a filter-edge resize when zoomed out.

Changes:

• Added shared pixel-based passband hit-test helpers to classify edge vs body interactions for narrow passbands.
• Updated active-slice mousePressEvent() logic to use the new edge/body classifier.
• Updated hover cursor edge detection in mouseMoveEvent() to use the same classifier.

Thanks @rfoust — this is a well-structured fix. Centralizing the edge/body classification so press, hover, the VFO-child event filter, and the QRhi polling path all agree is the right shape, and I verified the supporting details: setSpectrumCursor() already guards redundant installs (so the per-frame call in renderGpuFrame is cheap), VfoWidget builds all its children in buildUI() at construction (so installVfoCursorEventFilter catches them all), and the event filter never consumes events, so child buttons keep their clicks as described.

One real inconsistency — hover/press ordering for overlapping slices

sliceCursorShapeAt() checks the active overlay first, then inactive slices. mousePressEvent() does the opposite: the inactive-slice loop (badge → centerline → passband body, all emitting sliceClicked) runs before the active overlay's edge/body checks. So when an inactive slice's badge or passband overlaps the active slice's edge zone or passband — exactly the zoomed-out, slices-close scenario this PR targets — the cursor shows SizeHor/OpenHand (active-slice action) but the click activates the inactive slice instead. Since the whole point of the cursor work is previewing the action, suggest reordering sliceCursorShapeAt() to check inactive slices first, mirroring press order.

On the Copilot findings

• "filterInteriorGrabPx forces insideGrabPx >= 1, leaving a 7px passband only 5px of body" — mostly a false positive. There is no >= 1 clamp; for widthPx = 7, (7 - 6) / 2 == 0, so no interior pixels are stolen and the body is the full 6px. However, there is a genuine off-by-one for even widths: the edge zones include their boundary pixel (mx <= loX + insideGrabPx), so the body is widthPx − 2·insideGrabPx − 1 pixels — 5px instead of 6 for widths 8, 10, …, 22. If the ≥6px guarantee is meant to be strict, (widthPx - kFilterPassbandMinBodyPx - 1) / 2 fixes it. Minor either way.
• "Hover still uses a 5px grab radius vs 8px on press" — false positive. This PR deletes the old GRAB = 5 hover path; hover now goes through sliceCursorShapeAt() → filterEdgeHitAtPixel() with the same kFilterEdgeGrabPx = 8 as press.

Two small notes

1. The childAt() guard bypass in mouseMoveEvent means the #2355 tooltip protection no longer applies where overlay-menu buttons overlap passband/edge zones — QToolTip::hideText() paths can kill their tooltips again there. Probably an acceptable tradeoff for the cursor affordance, but worth being aware it partially reverts #2355 in those zones.
2. The validation section says "Manual reporter retest confirmed the cursor behavior was better before this push" — as written that says the reporter preferred the previous behavior. Assuming that's a typo for "better than before this push", but please confirm.

No scope, settings-convention, or resource concerns — the diff matches the stated scope and the new helpers are pure functions.

_{🤖 aethersdr-agent · cost: $10.5651 · model: claude-fable-5}

Claimed; read full diff, commit, PR body, both bot reviews, and all comments including today's inactive-slice follow-up.

Root causes verified real — all three. The edge grab zone overlap on narrow passbands is a direct consequence of std::abs(mx - loX) <= 8 with no passband-width awareness: on a 4px rendered filter both zones cover the entire passband. The child-widget cursor bypass and the inactive-slice ordering mismatch are independently reproduced by the QRhi polling path and the pre-edge badge check respectively — the three bugs are layered but structurally distinct.

Shared hit-test helpers are correct:

filterInteriorGrabPx — (widthPx - kFilterPassbandMinBodyPx - 1) / 2 with the -1 ensuring integer division rounds down, so the minimum body area is preserved at every boundary width. Returns 0 when widthPx <= kFilterPassbandMinBodyPx, collapsing both edge zones entirely on a sub-6px passband rather than producing a negative interior.

filterEdgeHitAtPixel — handles loX > hiX (LSB filter orientation) correctly via the lowIsLeft flag. The both-edges-in-range disambiguation by proximity to each edge is the same tie-breaking logic that was already in the old active-slice path (#764), now unified.

kFilterEdgeGrabPx = 8 used consistently across press and hover. The old code used GRAB = 5 in the hover path and GRAB = 8 in press — that mismatch meant the hover cursor preview didn't reflect the actual click zone. Consistent 8px is correct.

Cursor override mechanism is correct. Three QVariant properties save/restore each VFO child's prior cursor state without adding member variables. clearCursorOverride correctly distinguishes WA_SetCursor (restore) vs inheriting (unsetCursor). The active guard prevents double-saving on repeated calls before a clear. installVfoCursorEventFilter is called from addVfoWidget() so all children are covered at construction. eventFilter maps child coordinates to spectrum-local via mapFromGlobal() — correct for overlaid widgets.

sliceCursorShapeAt() ordering. Inactive slices checked before active — matches mousePressEvent priority after today's rebase, fixing Bug 3. The negative early-return on out-of-spectrum coordinates prevents false matches.

mouseMoveEvent child-widget guard. Allowing through when overSliceCursorTarget is true preserves VFO child tooltip behavior (#2355) while ensuring the cursor advertises the drag action even when a child button is underneath.

macOS normalization extracted to normalizedSpectrumCursorShape() and shared between setSpectrumCursor() and setCursorOverride() — eliminates the prior risk of the two paths diverging.

Scope discipline. SpectrumWidget.{cpp,h} only. Zero #3351 exposure. No conflict with #3547 (which modifies sliceColorForOverlay() — a different code region entirely).

CI fully green (all 6 checks including CodeQL, completed 14:20 UTC today). Already rebased onto upstream/main.

Approved.